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Abstract 


Source Description (SDES) items are normally transported in the RTP 
Control Protocol (RTCP). In some cases, it can be beneficial to 
speed up the delivery of these items. The main case is when a new 
synchronization source (SSRC) joins an RIP session and the receivers 
need this source’s identity, relation to other sources, or its 
synchronization context, all of which may be fully or partially 


identified using SDES items. To enable this optimization, this 
document specifies a new RTP header extension that can carry SDES 
items. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7941. 
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Introduction 


This specification defines an RTP header extension [RFC3550] [RFC5285] 
that can carry RTCP Source Description (SDES) items. Normally, the 
SDES items are carried in their own RTCP packet type [RFC3550]. By 
including selected SDES items in a header extension, the 
determination of relationship and synchronization context for new RIP 
streams (SSRCsS) in an RTP session can be optimized. Which 
relationship and what information depends on the SDES items carried. 
This becomes a complement to using only RTCP for SDES item delivery. 


It is important to note that not all SDES items are appropriate to 
transmit using RIP header extensions. Some SDES items perform 
binding or identify synchronization contexts with strict timeliness 
requirements, while many other SDES items do not have such 
requirements. In addition, security and privacy concerns for the 
SDES item information need to be considered. For example, the Name 
and Location SDES items are highly sensitive from a privacy 
perspective and should not be transported over the network without 
strong security. No use case has identified that such information is 
required when the first RTP packets arrive. A delay of a few seconds 
before such information is available to the receiver appears 
acceptable. Therefore, only appropriate SDES items, such as CNAME, 
will be registered for use with this header extension. 


Requirements language and terminology are defined in Section 2. 
Section 3 describes why this header extension is sometimes required 
or at least provides a significant improvement compared to waiting 
for regular RTCP packet transmissions of the information. Section 4 
provides a specification of the header extension and usage 
recommendations. Section 5 defines a subspace of the header 
extension URN to be used for existing and future SDES items and 
registers the appropriate existing SDES items. 


Definitions 
Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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2.2. Terminology 


This document uses terminology defined in "A Taxonomy of Semantics 
and Mechanisms for Real-Time Transport Protocol (RTP) Sources" 
[RFC7656]. In particular, the following terms are used: 


Media Source 

RTP Stream 

Media Encoder 

Participant 
3. Motivation 


SDES items are associated with a particular SSRC and thus with a 
particular RTP stream. The Source Description items provide various 
metadata associated with the SSRC. How important it is to have this 
data no later than when the first RTP packets is received depends on 
the item itself. The CNAME item is one item that is commonly needed 
either at reception of the first RTP packet for this SSRC or at least 
by the time the first media can be played out. If it is not 
available, the synchronization context cannot be determined; thus, 
any related streams cannot be correctly synchronized. Therefore, 
this is a valuable example for having this information early when a 
new RTP stream is received. 


The main reason for new SSRCs in an RTP session is when media sources 
are added. This can be because either an endpoint is adding a new 
actual media source or additional participants in a multi-party 
session are added to the session. Another reason for a new SSRC can 
be an SSRC collision that forces both colliding parties to select new 
SSRCs. 


For the case of rapid media synchronization, one may use the RTP 
header extension for rapid synchronization of RTP flows [RFC6051]. 
This header extension carries the clock information present in the 
RTCP sender report (SR) packets. However, it assumes that the CNAME 
binding is known, which can be provided via signaling [RFC5576] in 
some cases, but not all. Thus, an RTP header extension for carrying 
SDES items like CNAME is a powerful combination to enable rapid 
synchronization in all cases. 


The "Rapid Synchronisation of RTP Flows" specification [RFC6051] does 
provide an analysis of the initial synchronization delay for 

different sessions depending on the number of receivers as well as on 
session bandwidth (Section 2.1 of [RFC6051]). These results are also 
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applicable for other SDES items that have a similar time dependency 
until the information can be sent using RTCP. These figures can be 
used to determine the benefit of reducing the initial delay before 

information is available for some use cases. 


[RFC6051] also discusses the case of late joiners and defines an RTCP 
Feedback format to request synchronization information, which is 
another potential use case for SDES items in the RTP header 
extension. It would, for example, be natural to include a CNAME SDES 
item with the header extension containing the NTP-formatted reference 
clock to ensure synchronization. 


The ongoing work on bundling Session Description Protocol (SDP) media 
descriptions [SDP-BUNDLE] has identified a new SDES item that can 
benefit from timely delivery. A corresponding RTP SDES compact 
header extension is therefore also defined and registered in that 
document: 


MID: This is a media description identifier that matches the value 
of the SDP [RFC4566] a=mid attribute [RFC5888], to associate RTP 
streams multiplexed on the same transport with their respective 
SDP media description. 


4. Specification 


This section first specifies the SDES item RTP header extension 
format, followed by some usage considerations. 


4.1. SDES Item Header Extension 


An RTP header extension scheme allowing for multiple extensions is 
defined in "A General Mechanism for RTP Header Extensions" [RFC5285]. 
That specification defines both short and long item headers. The 
short headers (one byte) are restricted to 1 to 16 bytes of data, 
while the long format (two bytes) supports a data length of 0 to 255 
bytes. Thus, the RTP header extension formats are capable of 
supporting any SDES item from a data length perspective. 


The ID field, independent of a short or long format, identifies both 
the type of RTP header extension and, in the case of the SDES item 
header extension, the type of SDES item. The mapping is done in 
Signaling by identifying the header extension and SDES item type 
using a URN, which is defined in Section 5 ("IANA Considerations") 
for the known SDES items appropriate to use. 
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4.1.1. One-Byte Format 


The one-byte header format for an SDES item extension element 
consists of the one-byte header (defined in Section 4.2 of 
[RFC5285]), which consists of a 4-bit ID followed by a 4-bit length 
field (len) that identifies the number of data bytes (len value +1) 
following the header. The data part consists of len+l bytes of UTF-8 
[RFC3629] text. The type of text and its mapping to the SDES item 
type are determined by the ID field value. 


0 1 2 3 
OA 25°38 Ae 5 9G EB 898 50: 22 3) AS ib 6 “8 Os OF D2) BF Ae 5, 6 892-0: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| ID | len | SDES item text value ... | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 1 
4.1.2. Two-Byte Format 


The two-byte header format for an SDES item extension element 
consists of the two-byte header (defined in Section 4.3 of 
[RFC5285]), which consists of an 8-bit ID followed by an 8-bit length 
field (len) that identifies the number of data bytes following the 
header. The data part consists of len bytes of UTF-8 text. The type 
of text and its mapping to the SDES item type are determined by the 
ID field value. 


0 1 2 3 
0.1.2.3. 4°56 78°90 1.293) 4 5 6 7-8 9-0 12:53. 4 5-6 “7-8 ..9°0 1 
Hato to toto tatatatoto toto tatatatatitatoto ta tetatatititototetetatat 

| ID | len | SDES item text value ... 
Hato tbo toto tatatatoto toto tatatatatitotito to tatatatititototetatatat 


Figure 2 

4.2. Usage of the SDES Item Header Extension 
This section discusses various usage considerations: which form of 
the header extension to use, the packet expansion, and when to send 
SDES items in the header extension. 

4.2.1. One-Byte or Two-Byte Headers 
The RTP header extensions for SDES items MAY use either the one-byte 
or two-byte header formats, depending on the text value size for the 


used SDES items and the requirement from any other header extensions 
used. The one-byte header SHOULD be used when all non-SDES item 
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header extensions support the one-byte format and all SDES item text 
values contain at most 16 bytes. Note that the RTP header extension 
specification [RFC5285] does not allow mixing one-byte and two-byte 

headers for the same RIP stream (SSRC), so if any SDES item requires 
the two-byte header, then all other header extensions MUST also use 

the two-byte header format. 


For example, if using CNAMEs that are generated according to 
"Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names 
(CNAMES)" [RFC7022], if using short-term persistent values, and if 
96-bit random values prior to base64 encoding are sufficient, then 
they will fit into the one-byte header format. 


An RTP middlebox needs to take care choosing between one-byte headers 
and two-byte headers when creating the first packets for an outgoing 
stream (SSRC) with header extensions. First of all, it needs to 
consider all the header extensions that may potentially be used. 
Second, it needs to know the size of the SDES items that are going to 
be included and use two-byte headers if any are longer than 16 bytes. 
An RTP middlebox that forwards a stream, i.e., not mixing it or 
combining it with other streams, may be able to base its choice on 
the header size in incoming streams. This is assuming that the 
middlebox does not modify the stream or add additional header 
extensions to the stream it sends, in which case it needs to make its 
own decision. 


4.2.2. MTU and Packet Expansion 


The RTP packet size will clearly increase when a header extension is 
included. How much depends on the type of header extensions and 
their data content. The SDES items can vary in size. There are also 
some use cases that require transmitting multiple SDES items in the 
same packet to ensure that all relevant data reaches the receiver. 

An example of that is when CNAME, a MID, and the rapid time 
synchronization extension from RFC 6051 are all needed. Such a 
combination is quite likely to result in at least 16+3+8 bytes of 
data plus the headers, which will be another 7 bytes for one-byte 
headers, plus two bytes of header padding to make the complete header 
extension 32-bit word aligned, thus 36 bytes in total. 


If the packet expansion cannot be taken into account when producing 
the RTP payload, it can cause an issue. An RTP payload that is 
created to meet a particular IP-level Maximum Transmission Unit 
(MTU), taking the addition of IP/UDP/RIP headers but not RTP header 
extensions into account, could exceed the MTU when the header 
extensions are present, thus resulting in IP fragmentation. IP 
fragmentation is known to negatively impact the loss rate due to 
middleboxes unwilling or not capable of dealing with IP fragments, as 
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well as increasing the target surface for other types of packet 
losses. 


As this is a real issue, the media encoder and payload packetizer 
should be flexible and be capable of handling dynamically varying 
payload size restrictions to counter the packet expansion caused by 
header extensions. If that is not possible, some reasonable worst- 
case packet expansion should be calculated and used to reduce the RTP 
payload size of all RTP packets the sender transmits. 


4.2.3. Transmission Considerations 


The general recommendation is to only send header extensions when 
needed. This is especially true for SDES items that can be sent in 
periodic repetitions of RTCP throughout the whole session. Thus, the 
different usages (Section 4.2.4) have different recommendations. The 
following are some general considerations for getting the header 
extensions delivered to the receiver: 


1. The probability for packet loss and burst loss determine how many 
repetitions of the header extensions will be required to reach a 
targeted delivery probability and, if burst loss is likely, what 
distribution would be needed to avoid getting all repetitions of 
the header extensions lost in a single burst. 


2. If a set of packets are all needed to enable decoding, there is 
commonly no reason for including the header extension in all of 
these packets, as they share fate. Instead, at most one instance 
of the header extension per independently decodable set of media 
data would be a more efficient use of the bandwidth. 


3. How early the SDES item information is needed, from the first 
received RTP data or only after some set of packets are received, 
can guide if the header extension(s) should be in all of the 
first N packets or be included only once per set of packets, for 
example, once per video frame. 


4. The use of RTP-level robustness mechanisms, such as RTP 
retransmission [RFC4588] or forward error correction [RFC5109], 
may treat packets differently from a robustness perspective, and 
SDES header extensions should be added to packets that get a 
treatment corresponding to the relative importance of receiving 
the information. 


As a summary, the number of header extension transmissions should be 
tailored to a desired probability of delivery, taking the receiver 

population size into account. For the very basic case, N repetitions 
of the header extensions should be sufficient but may not be optimal. 
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N is selected so that the header extension target delivery 
probability reaches 1-P*N, where P is the probability of packet loss. 
For point-to-point or small receiver populations, it might also be 
possible to use feedback, such as RTCP, to determine when the 
information in the header extensions has reached all receivers and to 
stop further repetitions. Feedback that can be used includes the 
RTCP Extended Report (XR) Loss RLE Report Block [RFC3611], which 
indicates successful delivery of particular packets. If the RTP/AVPF 
transport-layer feedback message for generic NACK [RFC4585] is used, 
it can indicate the failure to deliver an RTP packet with the header 
extension, thus indicating the need for further repetitions. The 
normal RTCP report blocks can also provide an indicator of successful 
delivery, if no losses are indicated for a reporting interval 
covering the RTP packets with the header extension. Note that loss 
of an RTCP packet reporting on an interval where RIP header extension 
packets were sent does not necessarily mean that the RTP header 
extension packets themselves were lost. 


4.2.4. Different Usages 
4.2.4.1. New SSRC 


A new SSRC joins an RTP session. As this SSRC is completely new for 
everyone, the goal is to ensure, with high probability, that all RTP 
session participants receive the information in the header extension. 
Thus, header extension transmission strategies that allow some 
margins in the delivery probability should be considered. 


4.2.4.2. Late Joiner 


In a multi-party RTP session where one or a small number of receivers 
join a session where the majority of receivers already have all 
necessary information, the use of header extensions to deliver 
relevant information should be tailored to reach the new receivers. 
The trigger to send header extensions can, for example, be either 
RTCP from a new receiver(s) or an explicit request like the Rapid 
Resynchronization Request defined in [RFC6051]. In centralized 
topologies where an RTP middlebox is present, it can be responsible 
for transmitting the known information, possibly stored, to the new 
session participant only and not repeat it to all the session 
participants. 


4.2.4.3. Information Change 


If the SDES information is tightly coupled with the RTP data, and the 
SDES information needs to be updated, then the use of the RTP header 
extension is superior to RTCP. Using the RTP header extension 
ensures that the information is updated on reception of the related 
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RTP media, ensuring synchronization between the two. Continued use 
of the old SDES information can lead to undesired effects in the 
application. Thus, header extension transmission strategies with 
high probability of delivery should be chosen. 


4.2.5. SDES Items in RTCP 


The RTP header extension information, i.e., SDES items, can and will 
be sent also in RTCP. Therefore, it is worth making some reflections 
on this interaction. As an alternative to the header extension, it 
is possible to schedule a non-regular RTCP packet transmission 
containing important SDES items, if one uses an RTP-/AVPF-based RTP 
profile. Depending on the mode in which one’s RTCP feedback 
transmitter is working, extra RTCP packets may be sent as immediate 
or early packets, enabling more timely SDES information delivery. 


There are, however, two aspects that differ between using RTP header 
extensions and any non-regular transmission of RTCP packets. First, 
as the RTCP packet is a separate packet, there is no direct relation 
and also no fate sharing between the relevant media data and the SDES 
information. The order of arrival for the packets will matter. With 
a header extension, the SDES items can be ensured to arrive if the 
media data to play out arrives. Second, it is difficult to determine 
if an RTCP packet is actually delivered, as the RTCP packets lack 
both a sequence number and a mechanism providing feedback on the RTCP 
packets themselves. 


4.2.6. Update Flaps 


The SDES item may arrive both in RTCP and in RTP header extensions, 
potentially causing the value to flap back and forth at the time of 
updating. There are at least two reasons for these flaps. The first 
one is packet reordering, where a pre-update RTP or RTCP packet with 
an SDES item is delivered to the receiver after the first RTP/RTCP 
packet with the updated value. The second reason is the different 
code paths for RTP and RTCP in implementations. An update to the 
sender’s SDES item parameter can take a different time to propagate 
to the receiver than the corresponding media data. For example, an 
RTCP packet with the SDES item included that may have been generated 
prior to the update can still reside in a buffer and be sent 
unmodified. The update of the item’s value can, at the same time, 
cause RTP packets to be sent including the header extension, prior to 
the RTCP packet being sent. 


However, most of these issues can be avoided by the receiver 
performing some checks before updating the receiver’s stored value. 
To handle flaps caused by reordering, SDES items received in RTP 
packets with the same or a lower extended sequence number than the 
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last change MUST NOT be applied, i.e., discard items that can be 
determined to be older than the current one. For compound RTCP 
packets, which will contain an SR packet (assuming an active RTP 
sender), the receiver can use the RTCP SR timestamp field to 
determine at what approximate time it was transmitted. If the 
timestamp is earlier than the last received RTP packet with a header 
extension carrying an SDES item, and especially if carrying a 
previously used value, the SDES item in the RTCP SDES packet can be 
ignored. Note that media processing and transmission pacing can 
easily cause the RTP header timestamp field as well as the RTCP SR 
timestamp field to not match with the actual transmission time. 


4.2.7. RTP Header Compression 


When Robust Header Compression (ROHC) [RFC5225] is used with RTP, the 
RTP header extension [RFC5285] data itself is not part of what is 
being compressed and thus does not impact header compression 
performance. The extension indicator (X) bit in the RTP header is, 
however, compressed. It is classified as rarely changing, which may 
no longer be true for all RTP header extension usage, in turn leading 
to lower header compression efficiency. 


5. IANA Considerations 
This section details the following updates made by IANA: 
o Creation of a new sub-registry reserved for RTCP SDES items with 
the URN subspace "urn:ietf:params:rtp-hdrext:sdes:" in the "RTP 


Compact Header Extensions" registry. 


o Registration of the SDES items appropriate for use with the RTP 
header extension defined in this document. 


5.1. Registration of an SDES Base URN 


IANA has registered the following entry in the "RTP Compact Header 
Extensions" registry: 


Extension URI: urn:ietf:params:rtp-hdrext:sdes 


Description: Reserved as base URN for RTCP SDES items that are also 
defined as RTP compact header extensions. 

Contact: Authors of RFC 7941 

Reference: RFC 7941 


The reason to register a base URN for an SDES subspace is that the 
name represents an RTCP Source Description item, for which a 
specification is strongly recommended [RFC3550]. 
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5.2. Creation of the "RTP SDES Compact Header Extensions" Sub-Registry 
IANA has created a sub-registry to the "RTP Compact Header 
Extensions" registry, with the same basic requirements, structure, 
and layout as the "RTP Compact Header Extensions" registry. 

o Registry name: RTP SDES Compact Header Extensions 


o Specification: RFC 7941 


o Information required: Same as for the "RTP Compact Header 
Extensions" registry [RFC5285] 


o Review process: Same as for the "RTP Compact Header Extensions" 
registry [RFC5285], with the following requirements added to the 
Expert Review [RFC5226]: 


1. Any registration using an extension URI that starts with 
"urn:ietf:params:rtp-hdrext:sdes:" (Section 5.1) MUST also 
have a registered Source Description item in the "RTP SDES 
item types" registry. 


2. Security and privacy considerations for the SDES item MUST be 
provided with the registration. 


3. Information MUST be provided on why this SDES item requires 
timely delivery, motivating it to be transported in a header 


extension rather than as RTCP only. 


o Size and format of entries: Same as for the "RTP Compact Header 
Extensions" registry [RFC5285]. 


o Initial assignments: See Section 5.3 of this document. 
5.3. Registration of SDES Item 


IANA has registered the following SDES item in the newly formed "RTP 
SDES Compact Header Extensions" registry: 


Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname 


Description: Source Description: Canonical End-Point Identifier 
(SDES CNAME) 

Contact: Authors of RFC 7941 

Reference: RFC 7941 
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6. 


Security Considerations 


Source Description items may contain data that are sensitive from a 
security perspective. There are SDES items that are or may be 
sensitive from a user privacy perspective, like CNAME, NAME, EMAIL, 
PHONE, LOC, and H323-CADDR. Some may contain sensitive information, 
like NOTE and PRIV, while others may be sensitive from profiling 
implementations for vulnerability or other reasons, like TOOL. The 
CNAME sensitivity can vary depending on how it is generated and what 
persistence it has. A short-term CNAME identifier generated using a 
random number generator [RFC7022] may have minimal security 
implications, while a CNAME of the form user@host has privacy 
concerns, and a CNAME generated from a Media Access Control (MAC) 
address has long-term tracking potentials. 


In RTP sessions where any type of confidentiality protection is 
enabled for RTCP, the SDES item header extensions MUST also be 
protected. This implies that to provide confidentiality, users of 
the Secure Real-time Transport Protocol (SRTP) need to implement and 
use encrypted header extensions per [RFC6904]. SDES items carried as 
RTP header extensions MUST then use commensurate strength algorithms 
and SHOULD use the same cryptographic primitives (algorithms, modes) 
as applied to RTCP packets carrying corresponding SDES items. If the 
security level is chosen to be different for an SDES item in RTCP and 
an RTP header extension, it is important to justify the exception and 
to consider the security properties as the worst in each aspect for 
the different configurations. It is worth noting that the current 
SRTP [RFC3711] only provides protection for the next trusted RTP/RTCP 
hop, which is not necessarily end to end. 


The general RTP header extension mechanism [RFC5285] does not itself 
contain any functionality that is a significant risk fora 
denial-of-service attack, neither from processing nor from storage 
requirements. The extension for SDES items defined in this document 
can potentially be a risk. The risk depends on the received SDES 
item and its content. If the SDES item causes the receiver to 
perform a large amount of processing, create significant storage 
structures, or emit network traffic, such a risk does exist. The 
CNAME SDES item in the RTP header extension is only a minor risk, as 
reception of a CNAME item will create an association between the 
stream carrying the SDES item and other RTP streams with the same 
SDES item. This usually results in time synchronizing the media 
streams; thus, some additional processing is performed. However, the 
application’s media quality is likely more affected by an erroneous 
or changing association and media synchronization than the 
application quality impact caused by the additional processing. 
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As the SDES items are used by the RTP-based application to establish 
relationships between RTP streams or between an RTP stream and 
information about the originating participant, there SHOULD be strong 
integrity protection and source authentication of the header 
extensions. If not, an attacker can modify the SDES item value to 
create erroneous relationship bindings in the receiving application. 
For information regarding options for securing RTP, see [RFC7201]. 
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